Skip to content

feat(risk): runtime-tunable risk controls#162

Open
FurkanEdizkan wants to merge 15 commits into
testfrom
feat/runtime-risk-controls
Open

feat(risk): runtime-tunable risk controls#162
FurkanEdizkan wants to merge 15 commits into
testfrom
feat/runtime-risk-controls

Conversation

@FurkanEdizkan

Copy link
Copy Markdown
Owner

Summary

Makes the engine's five global risk limits — stop-loss, take-profit, per-order notional cap, daily-loss limit, and drawdown kill switch — editable at runtime from the Settings UI, applied on the next engine tick, without an engine restart. The enforcement math in trading/risk.py is unchanged; this wires config, tuning, and visibility around it.

  • Store-backed, no migration: limits live in the appsettings KV store (get/set_risk_*), read via RiskManager.from_store(session) each tick. Falls back to env risk_* for any unset limit, so existing env-configured deployments keep identical effective limits.
  • Disabled by default, UI pre-fills recommended values (5% SL / 10% TP / 15% drawdown; currency limits input-only) — behavior only changes on an explicit save.
  • Applies to every order path: strategy ticks, manual orders, and AI-signal confirmations all consult the runtime limits (not just strategy ticks).
  • Settings API: GET /api/settings exposes the five risk_* fields; PUT /api/settings/risk validates (ge=0, le=100 on %; ge=0 on amounts) and audits.
  • Settings UI: a "Risk controls" card with per-limit toggle/input, a "changes apply on the next tick — a stop-loss may immediately close a losing position" warning, and negative-input guards.

Built via spec → plan → subagent-driven TDD (two-stage review per task). Design docs: docs/superpowers/specs/2026-07-02-runtime-tunable-risk-controls-design.md, docs/superpowers/plans/2026-07-02-runtime-tunable-risk-controls.md.

Test Plan

  • Engine suite green (498 passed): store round-trip (all 5) + env fallback + explicit-zero; from_store precedence; per-tick enforcement + injected override; API read/update/validation; manual-order + AI-signal paths honor a stored cap (fail-before/pass-after verified)
  • Web typecheck 0 · lint 0 errors · build ✓
  • Manual smoke: Settings → Risk controls → arm stop-loss (pre-fills 5) → save → persists across reload; sim mode confirms an armed limit fires on the next tick
  • Confirm the 4 required CI status checks pass on this PR

🤖 Generated with Claude Code

FurkanEdizkan and others added 15 commits July 2, 2026 14:20
Approved brainstorming design: make the existing (but env-only, boot-time,
disabled-by-default) RiskManager limits editable at runtime from the Settings
UI. Engine reads limits from the settings store per tick; hybrid defaults
(disabled, UI pre-fills recommended values); backward-compatible env fallback.
Backtest simulation of limits deferred.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
TDD, bite-sized plan (7 tasks): store getters/setters, RiskManager.from_store
with env fallback, per-tick engine read (injected override preserved), settings
API read/update + validation, regenerated web client, Settings "Risk controls"
card with hybrid pre-fills, and final verification. Derived from the approved
2026-07-02 design spec.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…tingsUpdate

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant